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ABSTRACT 

2n« aPe ,K D P0rt l, 0n c a r mU,ti_t001 commercial/military environment combining software Domain Analysis tech 

non Assistant (SSA) and Software Reengineering Environment (SRE), developed by Computer Command and 

Contro! Company (CCCC) for Naval Surface Warfare Center (NSWC) and Joint Logistics Commanders CJI Ci and 
the Advanced Research Project Aeencv fARPA^ n • . _ g . cs '- omma naers (JLC), and 

Boeing forNAVArR PMA ^ (AKPA) STARS Software Engineering Environment (SEE) developed by 

a N rT A u PMA 205 T h paper descnbes transitioning these integrated tools to commercial use There is 

critical need for the transition for the following reasons: First, to date, 70% of programmers’ time is applied to 
software maintenance. The work of these users has not been facilitated by existing toofs. The addition of Software 

SSisi sSlt? and upgrading. In fact, to integrated tools will support the 

entire software life cycle. Second, the integrated tools are essential to Business Process Reengineering which seeks 

radical process innovations to achieve breakthrough results. Done well, process reengineering^delivere extraordinary 

nTs"^ Tu' Pr0dUCt,V ‘ ty 3nd P rofltabilit y- Most important, it discovers new opportunities for produS 
and services in collaboration with other organizations. Legacy computer software must be changed aSv to 

ZC t ‘ nn0V ; tlVe S,n "u S Pr ° CeSSeS - ThC intCgrated ,ools wil1 P rovide commercial organizations il£ 
inieo™. IT adV3ntag f s - T ! US ’ in turn ’ W,M ^crease employment by creating new business opportunities Thhd the 
Sy Cm W1 pr ° duce much hi « hcr q uali 'y software than use of the tools separately^The reason for this is 
“ Pgrad ' ng S f ware re < uires understanding of extremely complex' apphcSns which L 

CASF tnnk'thnI ,ntegratcd t0 °. ls ' ™ e radlcal savin 8 s in the tim e and cost associated with software, due to use of 
CASE tools that support combined Reuse of Software and Reengineering of Legacy Code will add an im tartan 

.mpetus to improving the automation of enterprises. This will be reflected in continuing prions as wTas ,n 
novating new business processes. The proposed multi-tool software development is based on state of the art 
technojogy, which will be further advanced through the use of open systems for adding new tools and experience in 
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1. Introduction And Summary 

The paper describes a multi-tool Software Engineering Environment for commercial and military applications 
combining software Domain Analysis techniques with those of Reusable Software and Reengineering of Legacy 
Software. 

The paper is based on the dual use of a version developed for the Department of Defense (DOD). The tools used in 
the military version must be modified for use in a commercial version. They are as follows: Software Specification 
Assistant (SSA) and Software Reengineering Environment (SRE) developed by Computer Command and Control 
Company (CCCC) under contracts with the Naval Surface Warfare Center (NSWC) and Joint Logistics Commanders 
(JLC), and the ARPA STARS Software Engineering Environment (SEE) developed by Boeing for NAVAIR PMA 

205. 

The Software Reengineering Environment (SRE) will facilitate: 

a) Translation of legacy software from old languages (Fortran, Cobol, C) to modem languages (C++ and 

Ada) and a modem open-ended Operating System (OSF). . 

b) Software Understanding and Documentation through analysis of relations within the software and 

their graphical display. 

c) Reorganization of software to obtain object oriented programs for concurrent network operations. 

The Software Engineering Environment (SEE) will facilitate: 

a) New software design. 

b) Reuse of code associated with a Domain. 

c) Code generation. 

This system is much more important than just combining capabilities of tools. It is a change in Computer-Aided 
Software Engineering (CASE) technology that will radically improve overall business automation. It will drastical- 
ly lower the cost and time to develop software, for the following reasons: 

First, 70% of programmer time is applied to software maintenance [5]. The work of these users is not facilitated by 
existing CASE tools. The Software Reengineering tools proposed here will also facilitate the work of users engaged 
in software maintenance and upgrading. The integrated tools will have a much wider coverage of the software life 
cycle and a much wider audience. 

Second, the integrated Software Engineering and Reengineering are essential to business process reengineering , 
which seeks radical process innovations to achieve breakthrough results [25], [42]. Done well, process reengineer- 
ing delivers extraordinary gains in speed, productivity and profitability. More importantly, it discovers new opportu- 
nities for products and services offered in collaboration with other organizations. Rapid offering of the new products 
and services is essential, in order not to miss business opportunities. Innovation in legacy computer software has 
been recognized in studies of reengineering as the major obstacle in rapidly reengineering manufacturing processes. 
Software must change rapidly to support the core requirements of business process engineering. These requirements 

are [27], [24]: 

a) Support of concurrent operations 

b) Leveraging human resources 

c) Sharing information 

d) Collaborating with other organizations 

The transitioned tools will offer commercial organizations the necessary means to attain strong, competitive 
advantages. This, in turn, will impact employment favorably by creating new business opportunities. 

Third, the integrated tools offer a new, higher quality of software than the tools offer separately. The reason for this 
is that producing or upgrading software requires keen user understanding of extremely complex applications, which 
is facilitated by the Software Reengineering tool [35], 

The transitioning from a military to commercial environment requires the following changes (only components of 
the military version that require changes for the commercial version are listed here): 

i) Translation of commercial programming languages Fortran, Cobol, C, and C++ into C++. The present translations 
in the military version are from CMS-2 and Ada to Ada. C++ is selected as the modem programming language 
preferred by the commercial community. 

ii) Integration of CCCC’s SRE tools with those of Domain Engineering and Application (DEA) [40], developed by 
Boeing under ARPA/STARS sponsorship, and with that of the PTECH tool [38] for Object Oriented Software De- 
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lions under the VMS Operating System. P e m, litary version operates on Digital’s Vaxsta- 

2 - Overview O f The System 

i^t!eS„T SttLT aPPr0Kh ' '■ ShoWS d * »P“«i»n of the Software 

oriented CASE tool. Xs rXlhL^et™ ^ ^ 

integration of three main tool groups, as follows: cycle for commercial use. Figure 1 shows the 

Software Specification Assistant (SSA): It is shown at the tnn uft „r c , , ... 

updating of software requirements and specifications In the It, Fl8 . Urc • ' SSA facil,tates the creation and 
[19]. A similar set of standards will Selected for the ? ^ VerS '° n “ conforms with DOD-STD 2167A 

importance of Software SpedtoS for ilt T/ “i ^ ^ 
repositories and tools. SSA guides instructs and informs c t *ft • y ' . SSA * an Inte 8 rated set of information 

requirements and specifications Typical users of SSA are n '"i COmpos '" g ’ u P da,ln g and evaluating preliminary 
Contractor,. SSA aTlow, a u,cr Kn ® DeVCl ° pment Manager - Softw ^ Support Activities, or 
an application system. Staff may ask complex techn^l CXtcn5,v ' * cnow ledgcba,c of information related to 
Fragments of retrieved ^""2“ SOftWare a " d retrieve answers 

inexperienced specifier in Updates t0 j; eIevant " ew documents. SSA leads the 

™ ~»u h : 

iS Sh0 7f al “ P ^ ° f 1 "P» '• * i-fporeres new 
Domain Specific Software Architecture tDSSAl ? aad for automatic program generation, following ARPA’s 
uaedinfhemilita^ ARPA STARS SEE for NAVAIR PMA 205. 
for a class of related applications in a Domain and a n ^. ineenn S* t0 define the process of producing software 

^e'sE^ca t n^* ) o!an^tioned^^h^OTninrerc’al a ' S ° c ° nta !’** ["i^for^otyect^riew^dwi^^l^ftwa^ 

PTEC already generates object orient 

ilpZS; w”h“ a » relaKd “I* “ f F » «™pte. the DSSA 

Command Control and Communications etc f 81 Once a ° c ^ Ul< ^ ance ’ Navigation and Control, Avionics, 
need fo, generating applied" ^ ^ chi, “'»' HI » developed, can be 

areas of interest, and will be populated by artifacts from leoar Wl i ^ developed by respective users for their 
Reuse Software artifacts and associated took The r g f y Jr° de \ Domain Engineering contains a repository of 
The DEA facilitates sel c,Ln of R « e “fL^and . ‘ ^7 Arehi, “'“ re is “lied the Domain EngZe r. 

The use, of the reposito^ and of ,h. ,^”1,! aW " iCa "°" SySK "' 

units (DOD-Standard 2167A) Each hierarchical » fl” * 7 ^'° WS * S “ nda,<l of hierarchical software 

hierarchy, its capahilitte, iure’rfJS^ to ,he a ' Chi, “ ; “ re 
architecture are listed in Table 1. The capabilities of rhe hil l f J The 8 ra Phs for documentation of the 
variability between hierarchical software units It is nnss hi y chlCa software un,ts determine commonality and 
referring to capabilities and se 1S f f° SS ‘ ble t0 naviga,e through ‘he Domain hierarchy tree by 

respective capabilities. S Hierarcht7| n Mftware C unhs t^y'^parametri^^and o on 'J nond H , y and variabili,/ of J, 
select parameters of generic software Alternated hieraroh' P 1 * d " d a code generation tool may be used to 

of their functionality Alternately, hierarchical units may be completely generated based on models 
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Figure 1: Overview of Integrating Tools for the Software Life Cycle. 


A series of tools are available in the DEA for application modelling, unit testing and conversion to concurrent 
operation: 

Software Reengineering Environment (SRE) [9]: SRE is shown at the bottom left of Figure 1. The SRE commercial 
version will consist of three main capabilities: 

(i) Software Understanding 4 . It consists of query and retrieval of graphic diagrams that illustrate the software from vari- 
ous perspectives. These diagrams are used to visualize specific aspects of the software. The diagrams are first di- 
vided into in-the-large and in-the-small diagrams. In-the-large diagrams visualize declarations of objects. In- 
the-small diagrams visualize execution statements within individual program units. The C++ program diagrams 
will be stored in a graphic form in the repository of a customized CASE system. A graphic query language is pro- 
vided for ad-hoc browsing in the graphic repository, consisting of the documents in Table 1. These graphs show 
relations between high or low level hierarchical units. This facilitates the understanding of the software’s architec- 
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ture as well as its code. Changes to the program can be made via the graphics used for visualization. This part of 
the military version can be used directly with no changes for the commercial version. The changes to C++ are all 
in the translation component (i). 

(n) Software Abstraction and Documentation: SRE partitions the software into multi-level hierarchical software units, 
in conformity with the standards for describing the software architecture. Software documents are then generated 
that describe the architecture in terms of the hierarchical software units, and describe the software in each unit from 

different perspectives shown in Table 1 below. This part of the military version can be used directly in the commer- 
cial version. 

(iii) S 0 fi™ are Capture and its Transformation to C++ and OSF: Fortran, Cobol, CorC++ source programs will be trans- 
lated into C++ Entity-Relation-Attribute (ERA) diagrams. This representation is the main vehicle for graphic pro- 
gram analysis and visualization. Multiple passes are made over the source code to achieve 100% translation to ob- 
ject-oriented C++. Visualization is used for query, retrieval, understanding and generating documentation of 
programs. In a first pass, the SRE will translate the code, statement by statement, into pseudo-C++. Next, the 
generated pseudo-C++ programs will be transformed into the C++ programming paradigm in a series of passes 
Each pass translates different aspects of the programming paradigm of the source language into the C++ program- 
ming paradigm (e.g., object declarations and classes). The Unix commands in legacy code will be replaced by OSF 
code having the same functionality. Other commercial subsystems (user interface and database) will be translated 
in this way as well. The military version uses Ada as the target language. It will have to add C++ as the target lan- 
guage. 


(i) 

Hierarchical Decomposition 
Diagrams 

Showing decomposition of the overall software into hierar- 
chical units. 

(ii) 

Flow Diagrams 

Showing flow of data and control within and between hierar- 
chical units. 

(iii) 

Interface Tables 

Showing the structure of inputs and outputs of each hierar- 
chical unit. 

(iv) 

[ Object/Use Diagrams 

Showing (for hierarchical units) where types or generics are 
defined and where they are used. 

(v) 

Context Diagrams 

Showing the library units and where they are used. 

(vi) 

Comments Text 

Showing the comments in each hierarchical unit. They are 
assumed to contain information on the hierarchical unit's 
capabilities. 


Table 1: Software Abstraction Documents Produced by SRE for Different Perspectives of the Software. 


The integration of the SSA, SRE, DEA and PTECH involves primarily two interfaces, also shown in Figure 1 They 
are as follows: J 

Interface Between SRE and SSA : This interface is shown at the middle left of Figure 1 [37], This interface provides 
a reverse process to produce information for the software requirements/specifications and other documentation from 
program code. SSA receives the documentation from SRE. 

Interface Between SRE and SEE : The SRE provides DEA and PTECH with software documentation in the form of 
high level graphic-views of the architecture as well as detailed graphic views of algorithms. The SRE can process 
Legacy code as well as Reuse code from the DEA repository. It generates key parts of the specifications of each 
hierarchical software unit. The capabilities of each hierarchical software unit in the specifications are used for 
establishing commonality and variability among the domain architecture hierarchical software units. 

Discussion of the Software Life Cycle Process using the integrated tools: The visualization provided by SRE 

facilitates human understanding. This is essential for successful employment of the entire Domain Specific Software 
Architecture (DSSA) concept. These SRE capabilities are needed for: 

i) Analyzing and understanding the programs in the Reuse software library of Domain Engineering and in the target 

software produced by Domain Application. ' ' ' 

ii) Analyzing, transforming and understanding existing software toexpand the domain architecture with new artifacts. 
This capability includes the transformation of existing programs in other source languages to C++ 
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DEA will use the SRE visualization graphs to compare the domain architecture’s unit and assess commonality and 
variability of hierarchical software units. The SSA will be used to specify the capabilities of the architecture’s 
hierarchical software units. 

Typically the tools will be used iteratively until a desired new or upgraded application system is obtained. As an 
example, consider the following scenario. Assume for simplicity that totally new application software is desired. 
The preliminary requirements have been composed by the application’s Program Manager. The platform to be used 
and its dynamics may be derived through modelling and simulation. The Specifier, with the aid of SSA, uses the 
preliminary requirements to compose the hierarchically structured specifications. The capabilities in the 
specifications are then communicated to the Application Engineer to select architecture units and generate the 
application software. If unable to do so, the Domain Engineer may be called to expand the scope of the domain. In 
either case, the SRE tool will be used to document and display the new domain and/or application software. 
Software Abstractions will be generated from the code. The Software Abstractions are next used by the Specifier, 
who employs SSA to update the specifications. The Domain Engineer will use the Software Abstractions to update 
the domain. The Application Engineer will use them to document the application software. This cycle may be 
repeated a number of times until satisfactory application software is realized. 

3. Discussion Of The Transition 

A military version of the system is partly operating (SRE) and partly in development (DEA). The transition into a 
commercial version will use the following technologies (The components of the military version which do not 
require alteration for the commercial version are not included): 

i) Translation from older commercial languages (Fortran, Cobol, C) and from C++ to C++ and from Unix to OSF ( 
instead of Ada in the military version). 

ii) Use of meta-languages for assembling multiple tools. They must be transitioned from the Digital VAX workstations 
and VMS Operating System used in the military version, to the OSF Operating System, which is portable among 
different vendors’ workstations. 

3.1 Translation Technology. 

The methodology used in the present military version of SRE for translation of military source languages to Ada will 
be transitioned to translate Fortran, Cobol, C, and C++ into C++ and Unix to OSF. The graphic representation of 
programs in C++ is similar to the graphic representation of Ada. DEA is language independent of the target 
language and PTECH produces C++ code as well as Ada. 

The processing in the SRE is shown in Figure 2 on the following page. SRE consists of four phases: Parsing and 
Transformation (P&T), Analysis and Restructuring (A&R), Software Understanding (SU) and Software Abstraction 
(SA). Only A&R will need to be revised. 

The data is stored in three repositories: Software Reengineering (SR), Software Understanding (SU) and Software 
Abstraction (SA). 

The input to P&T is a source language program. The output of P&T will be in Elementary Statement Language for 
C++ (ESL-C++). This is the graphic notation for visualizing C++ programs. An approach very similar to the one 
used in Ada is envisaged. Namely, the relations represented by edges in Ada can be retained in C++. These are: 
i) Edges between caller of a procedure and the procedure, ii) Edges between memory updating or referencing a 
variable and the variables’ declaration, iii) Edges between message source and its destination, iv) Edges between a 
class and its instances. It is stored as a tree in the SR Repository in ASCII form, and may be modified by the users 
updating the programs. 

A&R modifies and enhances the ESL-C++ tree in the SR Repository. It adds tuples that represent relations between 
statements. The results are restored in the SR repository. Visualization views are generated by A&R and stored in 
the SU Repository that is used for display by a CASE system. 

The DECdesign CASE system is being used for the SU tool. The Graphic User Interface (GUI) used in SU is 
customized for software reengineering and understanding. SU supports graphic retrieval and generation of C++ 
code. Once the programs are generated in C++, they can be added to a DEA Reuse Repository. 
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Figure 2: Tools and Repositories in the SRE. 
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ported to OSF. They are Is follows: V ^ 00 Dlgltal s VaxstatJ ons under VMS. They need to be 

ii) T^n^Re^ Honeywell’s AAA system is used [29], 

are used. 7 8 technology. Digital s A Tool Integration Service (AXIS) [14] and HP-Softbench 

nary/Repositoiy (CDEW) iJusedun^VMS 1 ^ S £ chan^dT' Digitai ’ s Cornm °" Data Dictio- 
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for the commercial world, and C++ as a target program language. ’ ° d ° “ S ° UrCe program Ia nguages 
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SRE: Software Reengineering I Accept Multiple Source Languages. 


Military (CMS-2, Jovial, Ada) 
Commercial (Cobol, Fortran, C, C++) 


SSA: Software Specification 


SEE: Software Reuse 
and Generation 


Generate Multiple Target Languages: [Ada, C++ 


Reorganization: I For Object Orientation 


Understanding: 


Abstraction: foi ows ujc. 


Graphical Query and Retrieval 


Follows User Partitioning of Software 
Multiple Diagrams of Software Architecture: 
Decomposition, Flow, Objects and 
their instantiations 


Very Large Repository of Do cuments (Text and Figures), 
Very Rapid Search, Edit and Compose Facilities 


Document Loading 


Process Management ______ 


Portability Option ^ _ 


Domain Engineerin g Driven From Specifications 
Domain Application D riven From Commonality/Variability 

Structured Reposito ry of Code and Specification 

Code Generation 

Concurrency Analysis 

Simulation - 


Table 2: Specification for Software Reengineering/Development For Emerging Era. 
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